…meInfo.kind

Promote getThumbnail(strategy) to the ProgressiveImage interface with a
default null implementation on BaseProgressiveImage. Cine images and
LoadedVtkImage inherit the null thumbnail automatically, so the data
browser falls back to modality text instead of spinning forever when a
cine DICOM is selected.

Replace every `instanceof DicomChunkImage|DicomCineImage` check with a
read of useDICOMStore().volumeInfo[id]?.kind === 'cine':

- isCineImage / getCineImage now branch on the store tag.
- datasets-dicom guards both the cine bail and the chunk-volume reuse
  against the same kind.
- segmentGroups skips the SEG-decoding branch for cine ids so a cine
  image can't reach chunkImage.getModality() and crash.
- PatientStudyVolumeBrowser just calls image.getThumbnail() — the
  workaround added for cine in the previous commit is gone.

ThumbnailStrategy moves to progressiveImage.ts; chunkImage.ts re-exports
it for back-compat. DicomChunkImage.getThumbnail return type tightens
from Promise<any> to Promise<string | null>.

Each 2D view now renders cine from its own local vtkImageData, so two
views can hold different frames or play independently without overwriting
each other's pixels. The canonical cine vtkImageData stays as a
compatibility surface for metadata and older consumers.

- DicomCineImage exposes getFrame(n) backed by FrameCache plus an
  inFlightFrames map so concurrent views share a single decode.
- VtkBaseSliceRepresentation builds a per-component CineRenderImage
  (vtkImageData + RGB scalars), binds the mapper to it for cine, and
  copies decoded frames into it with stale-token guards.
- startLoad() now seeds the canonical scalar buffer via getFrame(0); the
  public setFrame/currentFrame/getCurrentFrame/decodeToken API is removed.
- Scalar probe is unmounted and cleared for cine since it samples the
  canonical (frame-0) image.

getThumbnail() only ever supported MiddleSlice, so callers always passed
the same value and DicomChunkImage threw on anything else. Remove the
parameter and the enum.

The slice manipulators set the active view from a watcher on a ref that
is bidirectionally synced with sliceConfig.slice. Cine playback writes
to that ref every frame, so two playing views fought over which was
active and the green selection ring flickered.

Fire setActiveView only from the manipulator's user-input callback so
the active view changes on real wheel/drag input, not on programmatic
writes that come back through syncRef.

Cine images report dimensions [cols, rows, 1], so tools placed on any
frame past index 0 had their frame-of-reference resolution fail the
bounds check and jumpToTool returned early. Pass allowOutOfBoundsSlice
so we still get the axis and can drive the view's slice config.

- guard _importCineChunk against an existing non-cine cached image
- prune imageErrors[id] in removeImage
- defer per-view render-buffer disposal so the mapper drops its
  reference before the vtkImageData is freed
- surface JPEG dimension mismatch via reportError instead of console
- type PlayControls.spec wrapper so setProps accepts component props

getRenderSlice now takes an optional toolSlice param; the three tool
widgets that previously computed `tool?.slice ?? slice.value` inline
just pass both to the helper instead.

Consolidate the two store-write helpers behind a single patchConfig(clipId, patch),
fold the two-branch imageId watch into a unified pause-both-clips block, drop the
clampFpsValue wrapper and the redundant period guards.

Coronal/Sagittal 2D slots kept their orientation when a cine image was
dropped on them, and the view-type select was still offered. Force the
slice viewer to render Axial for cine images, swap the bottom-right
switcher for play controls, and clean up FPS label styling to match
surrounding overlay text.

- SliceViewer: inline effectiveOrientation; reuse isCine.value in
  windowingManipulatorProps
- SliceViewerOverlay: extract LOCKED_ORIENTATION_SUFFIXES list and a
  dedicated isLockedOrientationView computed; the previous
  showViewTypeSwitcher mixed cine and orientation concerns
- PlayControls: drop dead !viewId.value guard (non-nullable string prop)

- Fold applyDecodedFrame and markComplete into startLoad; each was
  called exactly once and the post-conditions ('status' === 'incomplete',
  loading === true) made the markComplete guards tautological at the
  call site
- Drop the unused scalars local in the inlined apply path
- Destructure { cols, rows } from header and { physicalDeltaX, physicalDeltaY }
  from region for less line noise

On remount (e.g. maximize toggle), the second watchImmediate called
resetCameraClippingRange against the default-position camera because
usePersistCameraConfig ran afterwards. The clip planes were computed
near the origin while the restored camera sits ~789 units away, so the
slice fell outside the clip volume and the canvas painted black.

Move usePersistCameraConfig above the clipping-range watcher so syncRef
writes the saved position/focalPoint/scale into the camera (sync flush,
immediate) before the near/far planes are computed.

jumpToTool and paint's cross-plane sync read view.options.orientation
directly, but SliceViewer forces every 2D view to render as Axial when
the image is a cine. The mismatch meant Reveal Slice updated only views
whose configured orientation happened to be Axial (typically the first
slot), and paint sync computed the slice index against the wrong LPS
axis on cine. Route both through getEffectiveViewAxis so the store
layer agrees with what's on screen.

- Trim verbose comments in VtkSliceView, useAnnotationTool, useVtkView
  to non-obvious WHY only; note why public cancelAnimation is unusable.
- Rename cineActiveOnly -> restrictToActiveView so the flag describes the
  behavior, not the trigger.
- Drop speculative `as any` casts and removeListener fallback in the
  interactor-lifecycle e2e; align BrowserLogEntry with WDIO's LogEntry.

…tiveViewAxis

useSliceInfo and crosshairs read view.options.orientation directly, which
diverges from what cine views actually render (Axial). Route all three
remaining sites — useSliceInfo (powers annotation widget plane math),
crosshairs (cross-view slice sync), and SliceViewer (its own inline cine
override) — through getEffectiveViewAxis so the cine collapse is applied
consistently and the helper is the single source of truth.

Unify the RGBA→RGB frame copy into a single helper in frameCache, route
pixel-spacing through the shared unitToMm util, and skip
patchDoubleKeyRecord when slice/playback updates wouldn't change state.
Tighten narrative comments left over from the prior simplify pass.

Moves JPEG-Baseline decode off the main thread via a small worker pool and
speculatively decodes the next frame on every getFrame, so forward playback
hits cache even when the clip exceeds the LRU budget. Measured on a 4-view
2x2 layout of color3d_jpeg_baseline.dcm at 30 FPS: per-view FPS rises from
~20 to ~29 and mean decode latency drops from ~50ms to ~12ms.

Have the worker produce a 3-component Uint8Array directly so the transferred
buffer is 25% smaller and the main thread publishes frames with a single
typed-array copy instead of a per-pixel RGBA→RGB loop. decodeNativeFrame
follows suit and writes RGB without the dummy alpha channel.

Replace the shims that masqueraded a cine clip as a Coronal/Sagittal/2D
slice viewer with a discriminated EffectiveView resolver. Slot ViewInfo
keeps representing user intent; the resolver computes render truth on
read, so a 3D-stored slot bound to cine renders CineViewer and snaps
back to the volume viewer when cine is replaced — without mutating
viewInfo.

- CineViewer / CineViewerOverlay with cine-specific scrub manipulators
- cinePlaybackStore gains frame; useCineFrame clamps against live range
- useSliceInfo / useAnnotationTool / paint / crosshairs route through
  computeEffectiveView; getEffectiveViewAxis and getRenderSlice deleted
- Annotation tools place via a Locator adapter, gaining tool.frame for
  cine; locatorMatches gates per-frame visibility and locatorPatch
  pins cine annotations to a degenerate FoR + frame
- isToolAllowedFor coerces Paint/Crop/Crosshairs to Select on cine and
  reacts to active-view kind changes (not just slot switches)
- ControlsStripTools isObliqueLayout derives from effective kind so
  cine in a stored-Oblique slot enables annotation buttons

Inferred return types and elided collection generics throughout files
added in the effective-view refactor; kept explicit annotations only
where inference would lose information (the EffectiveView union itself,
the inline tuple in useCineFrame's frameRange, the resolveSlotRendering
contract).

Each tool was destructuring {locator, frame} from useViewLocator and
then re-deriving slice via locatorPatch(locator.value).slice. The
composable already computes slice internally; surface it directly so
the three tool files drop a redundant computed each.

Move per-view render buffer, frame-decode watcher, and mapperInput out
of VtkBaseSliceRepresentation into a dedicated composable so the base
component reads as a generic slice rep again (190 -> 90 lines).